從當初透過閱讀《Essential Scrum》暸解 Scrum 以來，感覺多數的書籍、文件，常跟我們 Product Backlog 應該是顆粒度粗的在下面，顆粒度細的在上面，然後按照 Priority 去排序、一一拆解大型的顆粒度的 item 拆解為小的。

乍看之下很有道理，我心中也是這麼堅信著。但是隨著越來越多實務經驗，卻發現如果按照示意圖這樣線性排列，隨著 item 數量越來越多，Product Backlog 的排序成本就會越大，最後就會激積累著一堆萬年灰塵沉澱在 Product Backlog 最底下。

市面上也沒有一個應用程式或服務，能像示意圖一樣，透過面積大小讓我們直覺感受到顆粒度大小。只從每個代表 item 的橫列上顯示出來估算過的數字，也不太直觀。更何況通常我們有限的精力與時間下，只有辦法估算較上方的 Item。

最後，Product Backlog 對我們來說，就像是深不見底的海洋一樣。我們只有辦法看到太陽有辦法抵達的淺層，在深層一點，就是我們無力所及之處。我們對產品的視野也限縮在 1~3 Sprint 中，思考可能也漸漸侷限。

不確定有多少人也跟我經歷過類似的困惑？這就是我這系列嘗試想聊聊的話題。這些文不太會談書上講得如何整理 Product Backlog 的方式，更多是我在這幾年遇到的困境。更多著墨在，我使用了什麼工具，協助我服務的團隊管理 Product Backlog，如何視覺化他們，讓我們的視野就像在大霧中打開了遠光燈，可以更得更遠。甚至是在大海中的船隻，有了一枚指南針，讓我們不會迷失在附近的海域，而是持續往我們的目標前進。